Method and system for transmitting data from a transmitter to a receiver and transmitter and receiver therefor

ABSTRACT

Data from a transmitter is extended to include authentication data on the application level by an application protocol. The authentication data is used by the receiver to determine whether the transmitter is known by the receiver. If the transmitter is known by the receiver, the data is accepted. If not, the data is rejected.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is based on and hereby claims priority to GermanApplication No. 10001855.6 filed on 18 Jan. 2000, the contents of whichare hereby incorporated by reference.

BACKGROUND OF THE INVENTION

The invention relates to a method and a system and for transmitting datafrom a transmitter to a receiver, and to the transmitter and thereceiver therefor.

The transmission of data is known, by way of example, on the basis ofthe OSI reference model as described in Andrew S. Tanenbaum,Computer-Netzwerke; Wolfram's Fachverlag, Attenkirchen 1992, pages17-32. The OSI reference model (OSI model for short) from theInternational Standards Organization (ISO) has seven layers, each ofwhich has a different functionality (in terms of abstraction). In theOSI model, layer 1 corresponds to a physical layer, where data andmessages are transmitted from the transmitter to the receiver using aphysical protocol. In layer 2, a data link layer is provided, and a datalink protocol is used for transmission from layer 2 of the transmitterto layer 2 of the receiver. In a similar manner, layer 3, a networklayer, uses a network protocol between transmitter and receiver, andlayer 4, a transport layer, uses a transport protocol. In the OSI model,layer 5 corresponds to a session layer using a session protocol, layer 6corresponds to a presentation layer using a presentation protocol, andlayer 7 corresponds to an application layer using an applicationprotocol. In practice, many applications do not always permit exactnomination of strict boundaries specifically between the upper protocollayers, particularly layers 5 to 7. By way of example, within thecontext of Internet telephony, i.e. use of the telephone service usingthe medium of the Internet, the three layers above the transport layer 4combine to form an “application layer” for which, in a similar way to inthe implementation above, an “application protocol” is used.

A special feature of the OSI model and hence of all communication modelsfollowing the OSI model is that, as a result of the division intolayers, in each layer the bottom layers perform functions fullytransparently with regard to the currently considered layer and providethis upper layer with a service which is determined by all of thefunctionalities of the bottom layers. In this context, “transparent”means that currently considered layer does not need to concern itselfwith the functionalities of the bottom layers. In the case discussedhere, the application protocol can thus be used between an applicationlayer transmitter and an application layer receiver. This may covernumerous services, for example for switching, for protection or foractual transmission via a physical channel; these need no longer be aconcern from the point of view of the application protocol, particularlyas a user of this protocol.

Similarly with respect to this consideration, the individual layers have“protocol data units” (PDUs) between them which can be designedspecifically for each protocol of the respective layer. Thus, for eachlayer, the respective protocol can comprise a dedicated headercontaining administrative information for the respective layer'sprotocol, with this header also being able to be seen and used only bythe respective protocol's layer in accordance with the OSI model.Details about the design of the OSI model can be found in numerouspieces of literature, inter alia in those cited above.

When referring to application layer below, this denotes the layers abovethe transport layer (layers above 4). The application protocol alsodenotes the protocol for communication between a transmitter applicationlayer situated above the transport layer and a receiver applicationlayer situated above the transport layer.

A message authentication code (MAC) is known generally and denotes acryptographic checksum which is intended to be used to identify analteration in a message or in data (see Christoph Ruland,Informationssicherheit in Datennetzen (which translates as InformationSecurity in Data Networks), DATACOM-Verlag; Bergheim, 1993, pp. 61-63and 68-79).

A one-way hash function is known from Ruland, pp. 68-79, for example.Such a one-way hash function cannot be used to calculate the correctinput value for a given function value. Another feature is the absenceof collision, i.e. it must not be possible to use the one-way hashfunction to obtain the same output value for two different input values.

One difference between the hash code and the MAC is that the MACrequires a secret key in order to calculate it, whereas the hashfunction can be independent of a key and can be known publicly.

In addition, an asymmetric cryptographic method (also: public keymethod) is known, e.g. from Ruland, pp. 73-79. Each party involved in anasymmetric cryptographic method receives two keys, a public key and asecret (or private) key. In principle, the secret key can be derivedfrom the public key, with this task needing to be as complex aspossible. The asymmetric method can also be used to produce anelectronic signature (authentication) and/or to encrypt the content of amessage (using the receiver's public key) such that only the receivercan decrypt the message again using its secret key.

Finally, there is also a symmetric method, which requires a (secret) keyused both for encryption and decryption. An example of a symmetricencryption method is the DES algorithm.

A communication system is subject to a multiplicity of possible attackswhich can target, inter alia, the content of the messages interchangedin the communication system or the availability of the communicationsystem. Taking the example of Internet telephony, then it is firstlyimportant for the content of the telephone conversation not to be ableto be monitored by an unauthorized third party, and secondly it is alsonecessary for the third party not to be able to initiate countlesscalls, and hence for him not to interfere with the receiver andunnecessarily encumber the communication system. Such attacks are alsocalled denial-of-service attacks. Possible examples of such attacks aremass data or mass messages which are automatically generated and sent toone or more receivers, where they significantly encumber availabilityand performance. In the Internet telephony example, it is at leastunwanted for an Internet telephone to ring incessantly and hence notonly to load the network unnecessarily but also to distract thereceiver's attention. It is likewise perceived to be disruptive if anattacker interferes with the flow of communication between transmitterand receiver by sending unauthorized voice data.

To fend off attacks on a private communication network, “firewalls” areoften used which ensure, in particular, that the private communicationnetwork is separated from public networks. However, it is a simplematter for an attacker to send his meaningless (mass) data to addresseeswithin the private network as well, that is to say behind the firewall.There, these data are decoded and possibly reproduced. Thus, the effectachieved by the attacker is that, by way of example, the reproduction ofsuch meaningless data produces nothing but annoying audio interferenceor noise and hence restricts the bandwidth and availability of theprivate network. In the extreme case, part or all of the privatecommunication network can even crash.

In addition, an RTP protocol for transmitting media data (“payload”),i.e. video or audio data, is known from H. Schulzrinne: RTP: A TransportProtocol for Real-Time Applications; Internet Engineering Task Force,RFC1889, 1996.

One approach to holding off unwanted data is provided by the IPSECprotocol described S. Kent, R. Atkinson; IP Authentication Header,Internet Engineering Task Force, RFC2402, 1998 and S. Kent, R. Atkinson;IP Encapsulating Security Payload (ESP), Internet Engineering TaskForce, RFC2406, 1998. In this case, data packets of the Internetprotocol (IP data packets) can be encapsulated and can be protected interms of confidentiality and/or integrity (implicit senderauthentication). In addition, the IPSEC protocol affords a keymanagement method using a “cookie” mechanism (see D. Harkins, D. Carrel,The Internet Key Exchange (IKE), Internet Engineering Task Force,RFC2409, 1998), which can be used to fend off the mass data attacks(denial-of-service attacks) discussed above during the key managementphase. The cookie mechanism involves linking fast one-way hash functions(e.g. SHA-1), random numbers and IP addresses to one another. However,the first “cookie” transmitted from the transmitter to the receiver isnot protected, which results in a security gap. In addition, the IPSECcookie method is not suitable for ensuring protection against suchunwanted mass data on the application layer (for the applicationprotocol) under real-time conditions as well. However, the OSI layerstructure means that a drawback for IPSEC is, among other things, thatit is not possible to link IPSEC to the security functions of anapplication layer in this manner.

SUMMARY OF THE INVENTION

An object of the invention is to transmit data from a transmitter to areceiver, with the receiver ensuring that the data are not unwanted dataarising from a denial-of-service attack, for example.

First, the object is achieved by specifying a method for transmittingdata from a transmitter to a receiver, in which the transmitter extendsthe data by authentication data using an application protocol on theapplication layer. The authentication data are used by the receiver toascertain whether it knows the transmitter. If the receiver knows thetransmitter, the data are accepted, otherwise the data are rejected.

As stated above, depending on the protocol structure (cf. OSI model),data in each protocol layer have their own transparency with regard tothis protocol layer, i.e. the services in protocol layers beneath areperformed (without being seen by the current protocol layer).Advantageously, data packets on the application layer, in particular,are free of the administrative data associated with layers beneath, i.e.the data packets in the application layer have, besides theadministrative information for the application layer, only the datawhich are actually to be communicated. Accordingly, authentication inthe application layer is particularly advantageous, because the datapackets themselves, in contrast to layers beneath, are of significantlyreduced size. This small size has an advantageous effect on real timeand availability of the entire communication system. If the receiverknows the transmitter, i.e. particularly if the transmitter issuccessfully authenticated with respect to the receiver, the messagefrom the transmitter is accepted, in particular the data are stored.Otherwise, i.e. if the receiver does not know the transmitter, the dataare rejected, i.e. buffering does not take place. This is particularlyadvantageous if such a decision is made automatically.

In particular, available security functions and keys on the applicationlayer can advantageously be allocated to the individual applicationusers. This can advantageously be linked to the application data in afilter function outlined above. Special functions at the applicationlevel, such as picture and/or sound compression methods, canadvantageously be combined with security functions in the applicationlayer, which makes it possible to increase the end systems' performanceand reduces the implementation complexity; this also applies to theaforementioned filtering mechanism.

The described authentication mechanism in the application layer allowstransmitters and receivers which know one another to be separated fromtransmitters which are not known by the receiver and from which thereceiver does not accept any messages either. This allows an attack ofthe type described in the introduction (“denial-of-service” attack) tobe effectively prevented, i.e. unwanted mass data are actually rejectedwhen arriving at the transmitter.

In this context, special note will be made that the receiver in no wayhas to be an end receiver or addressee. Instead, the receiver itself canbe a switching entity, e.g. a switching node or a firewall withswitching functionality, and hence can act with regard to authenticationof the transmitter for the end receiver. Thus, in relation to the“firewall” example, it is possible to prevent superfluous network loadfrom being produced by rejecting the unwanted mass data before they evenenter the private communication network.

In this scenario (authentication in a switching entity), it isadvantageous, in particular, if the authentication data are generatedusing an asymmetric method, since it is also possible for the switchingentity, in the example the firewall, to ascertain from whom the data arecoming, without the decryption secret already needing to be known in thefirewall (as in the case of symmetric encryption) for this purpose. Thefirewall rejects unwanted mass data if it does not know the transmitter;in the other case, that is to say if the switching entity knows thetransmitter and the data are by no means unwanted, these data areforwarded to the receiver after the transmitter has been verified. Thereceiver can still use its private key to decrypt the data and processthem further locally (display them, store them, etc.) irrespective ofthe check on the data's origin, which has already taken place in thefirewall. It will be stressed once again that the decryption (in termsof confidentiality) of the data is performed by the addressee using itsprivate key in the asymmetric method described, whereas the origin ofthe message (which is determined for this addressee) can also be checkedin the switching entity using the public key of the sender—irrespectiveof the content of the message. Thus, an upstream filter functionalitycan be provided successfully by the switching entity. This results in aclear functional division between the filter function and theapplication function; the complexity of the terminals can be simplifiedas a result and the network traffic in the private communication networkcan be reduced.

One development is that the data are transmitted on a packet-orientedbasis. Another development is that the authentication data aredetermined by virtue of at least part of a protocol data unit, availableon the application layer, of the application protocol being encrypted bythe transmitter using a secret. In this case, the secret between thetransmitter and the receiver can be a key for symmetric encryption or akey pair for asymmetric encryption (public key method, see descriptionwith switching entity, for example). Decryption of the secretdetermines, particularly at the receiver end, whether or not thereceiver knows the transmitter. This is advantageous if data encryptionis available on the application level anyway and can also be used forthis purpose.

One refinement is that the authentication data are determined using partof the protocol data unit available on the application layer, inparticular a sequence number or a timestamp.

In particular, one development is that a one-way hash function is usedfor protection. Protection can also be effected using a messageauthentication code (MAC), with a key which is known only to thetransmitter and to the receiver additionally being necessary.

Another refinement is that, before the data are transmitted from thetransmitter to the receiver, authentication is carried out between thetransmitter and the receiver.

Another refinement is that the described method is used inpacket-switching telephone services, particularly within the context ofInternet telephony. Alternatively, the method can be used in switchingnodes and switching installations.

The object is achieved in another way by specifying a system fortransmitting data, in which a transmitter and a receiver are provided,the transmitter extending the data by authentication data using anapplication protocol on the application layer. The receiver uses theauthentication data to check whether it knows the transmitter. If thereceiver knows the transmitter, the data from the transmitter are used,otherwise the receiver rejects the data from the transmitter which isunknown to it.

The object is also achieved by specifying a transmitter for sending datato a receiver, which extends the data by authentication data using anapplication protocol on the application layer and sends them to thereceiver.

Finally, the object is achieved by specifying a receiver for receivingdata from a transmitter designed on the basis of the statements above,in particular, the receiver using authentication data within theapplication protocol on the application layer to determine whether itknows the transmitter. If it knows the transmitter, it uses the data,otherwise the receiver rejects the data. The system or the transmitterand the receiver are particularly suitable for carrying out theinventive method or one of its developments explained above.

Reference will now be made in detail to the preferred embodiments of thepresent invention, examples of which are illustrated in the accompanyingdrawings, wherein like reference numerals refer to like elementsthroughout.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other objects and advantages of the present invention willbecome more apparent and more readily appreciated from the followingdescription of the preferred embodiments, taken in conjunction with theaccompanying drawings of which:

FIG. 1 is a block diagram of a protocol architecture (protocol stack)for a communication system in the layer model;

FIG. 2 is a block diagram of an application layer with possibleprotocols;

FIG. 3 is a flowchart between the transmitter and the receiver fortransmitting data from the transmitter to the receiver;

FIG. 4 is a protocol data unit (PDU) of the application protocol(layer>5) with authentication data.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1 is a block diagram of a protocol architecture (protocol stack)for a communication system in the layer model, following the OSI modelmentioned above. A transmitter 104 and a receiver 105 interchangemessages via a physical connection 103. Both the transmitter 104 and thereceiver 105 have the same protocol architecture: layer 1 (110 and 111)represents a physical layer, layer 2 (109, 112) represents a data linklayer, layer 3 (108, 113) represents a network layer, layer 4 (107, 114)represents a transport layer and layer 5 (101 106) represents anapplication layer. Between the individual layers there is a respectivededicated protocol from a transmitter 104 to a receiver 105; for theapplication layer 101 or 106, this is the application protocol 102, forexample. From the point of view of layer 5 (101, 106), protocol dataunits having the format prescribed in the application protocol 102 aretransmitted from the transmitter 104 to the receiver 105. The layerssituated below the application layer represent functionalities which areprovided transparently for the application layer. On the basis of theOSI model, the functionalities have expediently been chosen to belargely independent of one another.

FIG. 2 is a block diagram of an application layer with possibleprotocols, based on an application concerning the transmission of mediadata (audio and video data). Thus, 101 and 106 represent the applicationlayer (layer 5) shown in FIG. 1 for the transmitter 104 and the receiver105. This application layer is in turn divided into a plurality ofsublayers. Thus, directly above the layer 4 is the real time transportprotocol (RTP) 201. This protocol allows voice and/or picture data to betransmitted in real time from one to possibly a plurality of points(addressees). A layer 206 contains a security application which compilessecurity functions of the application layer; associated securityprotocols provide for services such as

User authentication,

Access control

Confidentiality,

Integrity

Binding nature of the application data, and

Accounting.

Depending on the instance of application, audio data 203 and/or videodata 202 are used. For both alternatives, there are differentcompression standards, a few of which are shown by way of example inFIG. 2. For audio data, these are the standards G.711, G.722, G.723.1and G.729. For video data, these are the two picture compressionstandards H.261 and H.263. In the next abstraction stage (similarly withrespect to the OSI model) come the different possibilities for anapplication of audio or video data after compression and decompression(see block 204). One more abstraction level above, there is, by way ofexample, a user interface 205, which fully transparently provides a userwith the services beneath which have just been described. By way ofexample, a user, taking into account both the audio and the video data,can thus make use of video telephony, e.g. over the Internet, withoutspecifically needing to concern himself with any details of the servicesprovided by the layers beneath. He thus uses the video telephonyservice, visible to him, over the Internet transparently. In thiscontext, various alternative implementation forms can be situated belowhis service.

FIG. 3 is a flowchart for transmitting data from the transmitter 308 tothe receiver 307. In block 301, authentication data are produced on theapplication layer, and the protocol data unit (PDU) relevant to theapplication protocol is appended. In accordance with the arrangements ofthe application protocol, the data, including the authentication data,are transmitted to the receiver 307 (see connection 302). This is doneusing the functionalities or services available under the applicationprotocol. In block 303, the authentication data are checked in thereceiver 307 and there is a test (in block 304) to determine whether thetransmitter 308 is known to the receiver 307. If this is not the case,the procedure branches to block 305 and the data are rejected. If thetransmitter 308 is known to the receiver 307, the procedure branches toblock 306 and the data are processed further. The authentication betweentransmitter and receiver was successful, and the transmitted data arenot unwanted mass data.

FIG. 4 shows a protocol data unit (PDU) of the application protocol withauthentication data. What is shown in FIG. 4 is a protocol data unit(PDU) of the real time transport protocol (RTP, see 201 in FIG. 2) 401.Such an RTP packet 401 comprises an RTP header 406, encrypted media data404 and authentication data 405. The RTP header 406 comprises, interalia, a sequence number 402 and a timestamp 403. Both the transmitterand the receiver know a shared secret K, in this case indicated as akey, which is used to generate a message authentication code (MAC), onthe basis of the sequence number 402 and the timestamp 403 (see field405). An advantage with respect to encryption using a DES algorithm, forexample, is a field length of 64 bits.

As already described, such a packet sent by the transmitter isauthenticated at the receiver end such that (in relation to theapplication layer) a message authentication code is generated by field402 (sequence number) and field 403 (timestamp) on the basis of the key(K) known to the receiver. If this message authentication code is thesame as the field 405, then the arriving RTP packet 401 is a data packetcoming from a known transmitter, and the data are processed, for exampledisplayed or stored. In the other case, unauthenticated data areinvolved, the transmitter is unknown to the receiver and the entire RTPpacket is rejected.

The invention has been described in detail with particular reference topreferred embodiments thereof and examples, but it will be understoodthat variations and modifications can be effected within the spirit andscope of the invention.

1. A method for transmitting data from a transmitter to a receiver,comprising: providing transmitter-to-receiver authentication at a RealTime Transport Protocol (RTP) packet level as an application protocol onan application layer by inserting, at the transmitter, authenticationdata at end of a whole RTP packet payload; ascertaining, by thereceiver, whether the receiver knows the transmitter based on the RTPpacket level authentication data; and accepting, by the receiver, thewhole RTP packet payload, if the receiver knows the transmitter, andotherwise rejecting the whole RTP packet payload.
 2. The method asclaimed in claim 1, wherein the authentication data are determined basedon at least part of a protocol data unit available on the applicationlayer, and the application protocol being linked to a secret by thetransmitter.
 3. The method as claimed in claim 2, wherein the secretbetween the transmitter and the receiver is one of a key for symmetricencryption and a key pair for asymmetric encryption.
 4. The method asclaimed in claim 2, wherein the part of the protocol data unit availableon the application layer includes at least one of a sequence number anda timestamp.
 5. The method as claimed in claim 2, wherein the secret isan encryption operation performed using one of a one-way hash functionand a message authentication code with a key known only to the receiverand the transmitter to be authenticated.
 6. The method as claimed inclaim 2, wherein said ascertaining includes cryptographic verificationusing parameters and including at least one of a decryption operationand a cryptographic checksum check.
 7. The method as claimed in claim 2,wherein said ascertaining includes cryptographic verification usingparameters and including at least one of a decryption operation and acryptographic checksum check.
 8. The method as claimed in claim 2,wherein the linking to the secret is carried out by at least one ofcryptographical linking to at least one further parameter, particularlyby virtue of an encryption operation and a cryptographic checksum andkey information.
 9. The method as claimed in claim 8, wherein the secretbetween the transmitter and the receiver is one of a key for symmetricencryption and a key pair for asymmetric encryption.
 10. The method asclaimed in claim 8, wherein the part of the protocol data unit availableon the application layer includes at least one of a sequence number anda timestamp.
 11. The method as claimed in claim 8, wherein theencryption operation is performed using one of a one-way hash functionand a message authentication code with a key known only to the receiverand the transmitter to be authenticated.
 12. The method as claimed inclaim 8, wherein said ascertaining includes verification at the receiverto determine whether the receiver knows the transmitter.
 13. The methodas claimed in claim 12, wherein the secret between the transmitter andthe receiver is one of a key for symmetric encryption and a key pair forasymmetric encryption.
 14. The method as claimed in claim 12, whereinthe part of the protocol data unit available on the application layerincludes at least one of a sequence number and a timestamp.
 15. Themethod as claimed in claim 12, wherein the encryption operation isperformed using one of a one-way hash function and a messageauthentication code with a key known only to the receiver and thetransmitter to be authenticated.
 16. The method as claimed in claim 12,wherein the verification is cryptographic verification using parametersand including at least one of a decryption operation and a cryptographicchecksum check.
 17. The method as claimed in claim 16, wherein thesecret between the transmitter and the receiver is one of a key forsymmetric encryption and a key pair for asymmetric encryption.
 18. Themethod as claimed in claim 17, wherein the part of the protocol dataunit available on the application layer includes at least one of asequence number and a timestamp.
 19. The method as claimed in claim 18,wherein the encryption operation is performed using one of a one-wayhash function and a message authentication code with a key known only tothe receiver and the transmitter to be authenticated.
 20. The method asclaimed in claim 19, wherein the authentication is carried out betweenthe transmitter and the receiver before the data are transmitted fromthe transmitter to the receiver.
 21. The method as claimed in claim 20,wherein the receiver and transmitter are used in Internet telephony. 22.The method as claimed in claim 21, wherein the receiver and transmitterare each disposed in at least one of a switching node and a switchinginstallation.
 23. The method as claimed in claim 20, wherein thereceiver and transmitter provide packet-switched telephone services. 24.The method as claimed in claim 23, wherein the receiver and transmitterare each disposed in at least one of a switching node and a switchinginstallation.
 25. A system for transmitting data, comprising: atransmitter providing transmitter-to-receiver authentication at a RealTime Transport Protocol (RTP) packet level by inserting authenticationdata at end of a whole RTP packet payload; and a receiver to determinewhether the transmitter is known based on the RTP packet levelauthentication data, to accept the whole RTP packet payload if thetransmitter is known and to reject the whole RTP Packet payload if thetransmitter is not known, wherein the whole RTP packet payload comprisesa whole RTP packet payload header comprising at least one of a sequencenumber and a time stamp, and wherein the inserting the authenticationdata at the end of the whole RTP packet payload comprises generating amessage authentication code (MAC) according to a common secret betweenthe transmitter and the receiver and using the whole RTP packet payloadheader sequence number and timestamp, and appending the MAC to the endof the whole RTP packet payload, and if a MAC obtained by a receiver issame as a MAC contained in a transmitted whole RTP packet Payloadreceived by the receiver, the receiver accepts the transmitted whole RTPpacket.
 26. A transmitter for sending data to a receiver, comprising: aprocessor providing transmitter-to-receiver authentication at a RealTime Transport Protocol (RTP) packet level by inserting authenticationdata at end of a whole RTP packet payload; and a transmitter to send thewhole RTP packet payload including the inserted authentication data tothe receiver, wherein the whole RTP packet payload comprises an RTPheader comprising at least one of a sequence number and a time stamp,and wherein the processor inserts the authentication data at the end ofthe whole RTP packet payload by generating a message authentication code(MAC) according to a common secret between the transmitter and thereceiver and using the whole RTP packet payload header sequence numberand timestamp, and appending the MAC to the end of the whole RTP packetpayload.
 27. A receiver for receiving data from a transmitter,comprising: a processing unit, communicably connecting with thetransmitter, determining whether the transmitter is known based on thetransmitter providing transmitter-to-receiver authentication at a RealTime Transport Protocol (RTP) packet level by inserting authenticationdata at end of a whole RTP packet payload, and accepting the whole RTPpacket payload if the transmitter is known, and rejecting the whole RTPpacket payload if the transmitter is not known, based upon the RTPpacket level authentication data, wherein the whole RTP packet payloadcomprises a whole RTP packet payload header comprising at least one of asequence number and a time stamp, and wherein the processing unitobtains the authentication data added by the transmitter to the end ofthe whole RTP packet payload by generating a message authentication code(MAC) according to a common secret between the transmitter and thereceiver and using the whole RTP packet payload header sequence numberand timestamp.
 28. A method of transmitting data from a transmitter to areceiver, comprising: providing transmitter-to-receiver authenticationat a Real Time Transport Protocol (RTP) packet level by insertingauthentication data at end of a whole RTP packet payload; ascertaining,by the receiver, whether the receiver knows the transmitter based on theRTP packet level authentication data; and accepting the whole RTP packetPayload at the receiver, if the receiver knows the transmitter, andotherwise rejecting the whole RTP Packet payload, wherein the whole RTPpacket payload comprises a whole RTP Packet payload header comprising atleast one of a sequence number and a time stamp, and wherein theinserting the authentication data at the end of the whole RTP packetpayload comprises generating a message authentication code (MAC)according to a common secret between the transmitter and the receiverand using the whole RTP packet payload header sequence number andtimestamp, and appending the MAC to the end of the whole RTP packetpayload, and if a MAC obtained by a receiver is same as a MAC containedin a transmitted whole RTP packet payload received by the receiver, thereceiver accepts the transmitted whole RTP packet payload.